Object-oriented programming enables developers to visualize programmatic systems as groups and interactions of entities. To assist in this visualization, the programming paradigm includes a collection of virtual objects. Objects comprise both data structures and operations, known collectively as methods. Methods access and manipulate data structures. Objects having identical data structures and common behavior can be grouped together into classes. Each object inherits the data structure and methods of the particular class from which it was instantiated. Further, a hierarchical inheritance relationship exists between multiple classes. Each object can receive messages, process data, and send messages to other objects. Each object can be seen as an independent mechanism with a distinct role or responsibility.
Aspect-oriented programming enables methods to cross-communicate. More particularly, aspect-oriented programming allows programmers to use abstraction and decomposition to break apart large problems into smaller, more manageable subparts. Aspects facilitate the talking among methods. An aspect may comprise a portion of program code that can be woven across multiple program code points.
In one example, aspect-oriented programming may be used in a funds transfer application. A fund transfer program is composed of codes that execute SQL statements to transfer a remittance amount from a remittance account to a receiving account, when the remittance account, the receiving account and the remittance amount are entered. For the fund transfer, a user's computer must be checked if an anti-hacking program is loaded, and the user must be authenticated as a valid user. Further, it must be checked that the counterpart bank has properly processed the fund transfer, and the details of the fund transfer must be logged on the system. That is, in order to process a fund transfer, not only the fund transfer function, but also the additional functions such as security, authentication and log functions must be implemented at the same time. The codes for the additional functions are coded in a variety of programs, which are scattered over the system, other than the fund transfer programs. Here, the implementing functions (i.e., fund transfer) are the core concerns, while the additional functions (i.e., security/authentication/log) are the cross-cutting concerns.
In the absence of aspect-oriented programming, a programmer wishing to insert, modify, replace, or delete a portion of code with primary or cross-cutting concerns implemented therein must find out and modify all the codes of the programs scattered over the system by hand, one by one. That is, since both the core and cross-cutting concerns are implemented in one program in this method, the readability of the program is decreased, making modification of the code difficult. Accordingly, the development and maintenance of a program cannot be easily accomplished.
Aspect-oriented programming was developed to address this problem. Namely, aspect-oriented programming defines a methodology that deals with cross-cutting concerns. In aspect-oriented programming, one program is developed using the codes that implement cross-cutting concerns, and another program is developed using the codes that implement core concerns. The aspect-oriented programming describes the specifications for weaving the two programs using the point cut information. A program using the aspect-oriented programming methodology is referred to as an aspect, while a program using a conventional programming methodology is referred to as a base program. Here, the point cut is the information on the location of a base program, or application, where a specific code fragment of an aspect program is inserted.
Essentially, aspect-oriented programming allows the introduction of new functionality into objects without the objects' needing to have any knowledge of that introduction. AspectJ is an example familiar to those skilled in the art of aspect-oriented programming. AspectJ is a simple and practical aspect-oriented extension to Java. With just a few new constructs, AspectJ provides support for modular implementation of a range of crosscutting concerns. In AspectJ's dynamic join point model, code is compiled into standard Java bytecode. Simple extensions to existing Java development environments make it possible to browse the crosscutting structure of aspects in the same kind of way as one browses the inheritance structure of classes.
AspectJ allows programmers to define special constructs called aspects. Aspects can include several entities unavailable to standard classes. For instance, inter-type declarations allow a programmer to add methods, fields, or interfaces to existing classes from within the aspect. Pointcuts allow a programmer to specify join points (well-defined moments in the execution of a program, like method call, object instantiation, or variable access). Pointcuts are expressions (quantifications) that determine whether a given join point matches. Advice comprises an aspect-oriented programming feature that allows a programmer to specify code to run at a join point matched by a pointcut. The actions can be performed before, after, or around the specified join point. Traditionally, the aspects of AspectJ and other aspect-oriented programming languages run on application threads (short for thread of execution: a way for a program to split itself into two or more simultaneously running tasks) inside an application container.
An application container refers to a software engine that hosts applications to clients. Application containers offer infrastructure for applications that include fundamental features, such as security, transaction, data access, naming services, etc. Therefore, the applications can focus on business logics.
When an application is executed within a container, it is executed with service contexts provided by the application container. These service contexts represent the security service, naming service, transaction service, resource management service, to name a few. During the execution, the container automatically establishes these service contexts on the application thread for applications to use based on the environment and the deployment information. In one application, for instance, established context information comprising service contexts may include contextual information of a request that is evaluated to determine if access to a resource should be allowed.
Traditional aspects run in the same thread as the above mentioned base programs. However, some products, for example, the JBoss aspect-oriented programming language, have adopted asynchronous aspects to asynchronously invoke a thread to run the aspect outside of the application container. This can improve the performance of the base programs in a multi-threaded environment by not holding the base application thread.
When an aspect is run asynchronously outside of a container, another thread must be initialized for the aspect. Because the new thread is started outside the application container, the new thread cannot access the service contexts of the container. The application loses all the service contexts associated with the thread that the base program was running. Consequently, commercial applications that have adopted running aspects asynchronously are limited to logging, tracing, or auditing operations. That is, there is no effective way of asynchronously running an aspect outside of a container in a manner that accesses service contexts.
Therefore, what is needed is a way for an aspect to run outside of an application container without losing all of the service contexts associated with the thread that the base program is running.